专利摘要:
The invention particularly relates to the control of an ancillary operation related to the execution of a main transaction in a bank payment set comprising at least two separate client devices (215, 230) and a third device connected to a system ancillary operations management, configured to perform a main transaction between the two client devices. After having received from the third party device, in the ancillary operations management system, information relating to the execution of the main transaction between the two client devices, at least one execution rule of the annex operation is identified according to less a first information received information. The annex operation is then executed according to said at least one identified rule and at least a second information of the received information, distinct from the first information.
公开号:FR3031410A1
申请号:FR1550025
申请日:2015-01-05
公开日:2016-07-08
发明作者:D'alancon Ghislain Audemard
申请人:Heoh;
IPC主号:
专利说明:

[0001] The present invention relates to the management of financial transactions made by debtors to creditors via bank accounts of the latter. More specifically, the invention relates to methods and devices for controlling ancillary transactions related to the execution of main transactions, for example donation management following payments by credit card, made using devices connected by a communication network. While traditionally donations were made autonomously, for example by sending a check or a transfer to an organization of general interest or giving money to a representative of an association, there are now applications implemented computer-based (that is, in practice, on computers, personal assistants, smartphones, or the like). An essential feature of computer-implemented donation collection mechanisms is the quality of the interfaces for making donations so that a user is not inclined to discard an offer of donations for reasons of complexity, excessive time, uncertainty as to the amount, the beneficiary or the reliability of the procedure, etc. While these mechanisms generally obey simple monetary rules by proposing, for example, rounding up an amount to be paid for a purchase at the same time. higher integer or pay a predetermined amount for each purchase, the implementation is generally complex to meet the needs of user simplicity and security regarding transactions. In addition, there is a significant demand for traceability of donations, especially for tax purposes.
[0002] FIG. 1 schematically illustrates an environment in which a donation collection mechanism can be implemented, enabling a customer to make a micro-donation during a purchase, for example a donation of the difference between the price to be paid and this price rounded up to the next integer. As illustrated, the environment 100 allows a customer 105 having a payment card to make purchases from a merchant with an IT infrastructure 110. In addition to this infrastructure, the environment 100 here includes a computer system 115 linked to a merchant's bank, a computer system (not shown) linked to a customer's bank and a computer system 120 linked to a bank of an NGO-type organization 125 (acronym of Non-Governmental Organization).
[0003] The merchant's IT infrastructure 110 includes here, in particular, an accounting computer system 130, cash register software 135 associated with a cash register operated by a cashier and a payment terminal 140. The computer accounting system 130 and the cash register software box 135 are connected to each other by a communication network, for example a network of Ethernet type implementing the IP protocol (abbreviation of Internet Protocol in English terminology). The computer systems linked to the banks are interconnected with the accounting computer system 130 and the payment terminal 140 by an Internet type communication network, the data exchanges being secured, for example by encryption. The donation collection mechanism is generally implemented primarily in the accounting computer system 130 of the merchant as well as in his cash register software. When a customer goes to the cash register to pay for his purchases (step (D), of an amount marked M, the cashier asks him if he wishes to donate an amount marked D (step 0 If the customer refuses, the payment process continues in the traditional way (not shown), if the customer agrees to donate (step 0), the cashier presses a specific button to calculate a donation value based on the upper rounding of the purchase amount, passes a specific barcode to obtain a similar result or enters the donation amount using the cash register software (step G '). made by adding a particular reference to the list of references of the products purchased by the customer, this particular reference designating a donation and allowing, if necessary, the seizure of a free amount by the hostess. particular references p may be used to designate each organism to which the donation is to be made. The donation is thus integrated into the receipt, the total amount indicated, noted T, includes the amount of actual purchases (A //) and the donation amount (D). In other words, T = M + D. In a next step (step 0), the total amount (T) indicated on the receipt, the amount of actual purchases (A //) and the amount of the donation (D ) are transmitted by the cash register software 135 to the accounting computer system 130 of the merchant. If the payment of purchases is made by credit card (and not in cash or by check), the cash register software automatically transmits the amount to be paid (T) to the payment terminal 140. Alternatively, this amount is entered by the hostess. cash box on the payment terminal 140. If it is authorized, the customer validates the payment using his secret code. The computer system of the merchant's bank collects merchant receipts, typically periodically, and presents in bank intermediation the amount of payments (T = Mou T = M + D depending on whether the customer has made a donation or not) to credit a merchant account of a corresponding amount (step 0). At the same time, the merchant's accounting computer system 130 updates account journals in which the actual purchase amounts (M) and the donation amounts (D) are shown, typically by beneficiary organization. The separate management of the amounts of the actual purchases (M) and the amounts of the donations (D) is necessary for accounting reasons (related for example to VAT, acronym for Value Added Tax) and tax (especially for the calculation of the figure in which donations must not be returned). The donations account log is used by the merchant to periodically pay, for example every month, the total amount of donations received on behalf of one or more organizations. Such payments are typically made by order of the merchant to his bank, the latter executing the transaction order (steps 0 and Oc). The organization (s) then have donations made to carry out their missions (step 0). It is observed here that the mechanisms for collecting donations or micro-donations such as that described with reference to FIG. 1 require, for their implementation, substantial modifications of the devices used. Thus, in particular, it is necessary to modify the cash register software and / or to add a software cooperating with it, in order to allow the entry of at least one particular reference designating a donation and allowing the calculation of an amount associated or the seizure of an associated free amount, so that a particular item, not subject to VAT, is added to a receipt. It is also necessary to modify the merchant's computerized accounting system to allow separate management of the actual purchase amounts and the donation amounts, to allow the processing of references of products treated as donations and not subject to VAT (these amounts do not have to enter the calculation of turnover), to manage different account journals and to credit external accounts (accounts associated with organizations like NGO) as well as to calculate the exact amount of the turnover. In addition, it should be noted that the implementation of these mechanisms for collecting donations requires the involvement of cashier staff with clients. Thus, for example, cashiers must do the "quest" with customers by asking them to make a donation and, if necessary, manage the initiation of the donation management process. This extra work is generally considered unpleasant by cashiers who feel they are begging for donations. In addition, this procedure may have an unpleasant psychological influence and be considered intrusive by the client who feels trapped to the extent that a refusal may be misunderstood by a cashier or a customer located nearby when the question is asked.
[0004] Thus, the constraints imposed by these mechanisms of donation collection have important consequences. In addition, there is a risk of a significant slowdown in cash flow because of the complexity of the procedure.
[0005] Finally, the changes to be made to the cash register software and the accounting system of the merchant are very expensive (typically of the order of several million euros in the context of a chain operating at the national level). It is observed here that the modifications are very difficult to export from one trader to another, which implies a repetition of the modification operations and therefore the related costs. Finally, the transfer and management of the funds are the responsibility of the merchant, without real checks possible. The traceability of donations is not ensured, leading to problems such as tax exemption problems.
[0006] The invention solves at least one of the problems discussed above. The subject of the invention is thus a method for controlling an ancillary operation related to the execution of a main transaction, this method being implemented in an ancillary operations management system connected to a third party device of a bank payment set further comprising at least two separate client devices, the bank payment set being configured to perform a main transaction between the two client devices, and comprising the following steps, - receiving information relating to the execution of said main transaction between the two client devices, said information being received from said third party device; identification of at least one execution rule of the annex operation according to at least a first piece of information of said received information; and performing the annex operation according to said at least one identified rule and at least one second information of said received information, distinct from said first information.
[0007] The method according to the invention thus offers the possibility of making donations during payment on a payment terminal without modifying cash register software and accounting computer systems equipping merchants. Only the addition of a data processing module from the payment chain is necessary, without modification of the latter. This module is typically added to a piece of equipment of the payment chain, for example equipment of a bank issuing a payment card used for payment, without modification of the payment flows. The IT implementation costs of such a solution as well as the reliability of the solution are therefore advantageous. The collection of donations is particularly fast because it is completely transparent, for the debtor and the creditor, at the time of execution of the main transaction. Cashiers are not asked to collect donations.
[0008] In addition, the installation of the donation management method according to the invention is particularly simple. In addition, it allows real control and traceability of donations. According to a particular embodiment, the method further comprises a step of configuring said at least one execution rule in said ancillary operations management system. According to a particular embodiment, the method further comprises a step of storing at least one piece of information relating to the execution of said annex operation and a step of creating a history of execution of side operations.
[0009] According to a particular embodiment, said step of performing the annex operation comprises a step of transmitting data to at least one device separate from said third party device. According to a particular embodiment, said data transmitted to at least one device separate from said third party device comprises a debit order and a credit order. According to a particular embodiment, said steps of identification of at least one rule and execution of the annex operation are performed periodically according to information previously received and stored. The invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer. The benefits provided by this computer program are similar to those mentioned above. The invention also relates to a device for controlling ancillary operations related to the execution of main transactions, said device comprising: a database; - a module for acquisition and management of ancillary operations; and, a calculation module, the acquisition and ancillary operations management module and the calculation module being configured to receive data from a third party device of a bank payment set further comprising at least two separate client devices, the bank payment set being configured to perform a main transaction between the two client devices; and o at least partially identifying and executing an execution rule of an ancillary operation stored in the database according to received data. The device according to the invention thus offers the possibility of making donations during a payment on a payment terminal without modifying the cash register software and accounting computer systems equipping the merchants. Only the addition of a data processing module from the payment chain is necessary, without modification of the latter. This module is typically added to a piece of equipment of the payment chain, for example equipment of a bank issuing a payment card used for payment, without modification of the payment flows. The IT implementation costs of such a solution as well as the reliability of the solution are therefore advantageous. The collection of donations is particularly fast because it is completely transparent, for the debtor and the creditor, at the time of execution of the main transaction. Cashiers are not asked to collect donations. In addition, the installation of the device according to the invention is particularly simple. In addition, it allows real control and traceability of donations.
[0010] According to a particular embodiment, the device further comprises a configuration module, the configuration module for storing in said database and the setting of rules for executing ancillary operations. According to a particular embodiment, the device further comprises a data acquisition communication interface configured to receive data from said third party device. According to a particular embodiment, said data acquisition communication interface is unidirectional. According to a particular embodiment, the device further comprises a configuration communication interface configured to enable a user to enter, set or modify a rule for executing ancillary operations. According to a particular embodiment, said configuration communication interface provides Internet access to a remote device. According to a particular embodiment, the device further comprises a communication interface configured to transmit data to said bank payment set when performing an ancillary operation. Other advantages, objects and features of the present invention will be apparent from the following detailed description, given by way of non-limiting example, with reference to the accompanying drawings, in which: FIG. 1 schematically illustrates an environment in which implemented a fundraising mechanism allowing a customer to make a micro-donation during a purchase, for example a donation of the difference between the price to be paid and this price rounded up to the next integer; FIG. 2 diagrammatically illustrates a first example of an environment in which a particular embodiment of the invention can be implemented; FIG. 3 schematically illustrates a system for managing subsidiary operations; FIG. 4 schematically illustrates a second exemplary environment in which a particular embodiment of the invention can be implemented; and FIG. 5 illustrates an exemplary information processing device adapted to implement, at least partially, an embodiment of the invention. According to a particular mode of implementation of the invention, a mechanism for controlling ancillary operations related to the execution of main transactions, implemented by computer, for example a mechanism for collecting donations, uses a system specific to a main transaction execution system for receiving data therefrom, without interacting with this main transaction execution system. Thus, the main transaction execution system is only slightly modified, only to transmit information relating to the execution of main transactions.
[0011] A composite transaction here comprises a main transaction and at least one ancillary transaction whose execution automatically results from that of the main transaction. Such ancillary transactions typically involve amounts and beneficiaries different from those of the main transaction. It is recalled that a transaction is a commercial transaction for the part that is the subject of a particular embodiment of the invention, a transfer of a monetary sum between a debtor and a creditor.
[0012] As an illustration, a composite transaction may include the settlement of a purchase (main transaction) combined with a donation (ancillary transaction). According to a particular embodiment, the management of donations is essentially entrusted to a particular computer system for the purpose of managing requests for donations and the management of donations themselves. This computer system for managing donation requests and managing donations themselves is called the ancillary operations management system. This is, for example, a computer system implemented by a server connected to a bank server. It is recalled here that the known model, in electronic banking, under the name of four corners model includes a cardholder payment card, a payment terminal of a merchant, the merchant's bank and the bearer's bank, two banks being connected to each other via authorization networks also called bank intermediation network. According to this four-corner model, a customer provided with a payment card, for example a Visa-type card (Visa is a brand), can pay for a purchase from a merchant with a payment terminal. The payment card is associated with a bank account (customer account) managed by a computer system of a bank (typically the bank having issued the bank card or on behalf of which the bank card has been issued). Similarly, the payment terminal is associated with a bank account (merchant account) managed by a computer system of a bank. To make a purchase transaction, a customer presents his credit card to a payment terminal of a merchant to which the amount has been transmitted manually or automatically. After validation of the purchase by the customer, for example by entering a PIN or PIN (acronym for Personal Identification Number in English terminology), the payment terminal usually makes a request for authorization that is transmitted to the computer system of the cardholder's bank via the merchant's bank's computer system and a bank intermediation network.
[0013] The message is advantageously encrypted and includes the identifiers of the customer and the merchant as well as the amount to be transferred. After authentication and verification, including the identity of the customer and that of the merchant and the balance of the debit account, a transfer acceptance message, preferably encrypted, is sent by the computer system of the customer's bank to the system computer of the merchant's bank. After receiving a transfer acceptance message, a credit message is transmitted by the computer system of the merchant's bank to the address of the bank's computer system managing the bank account associated with the payment card used via the bank. banking intermediation network. This message is preferably encrypted. It is observed here that requests for banking intermediation can be accumulated and carried out in a deferred manner. The banking intermediation network may be, for example, the banking intermediation network MasterCard, Visa, GIE Bank Card, SWIFT, STET or Target 2 (MasterCard, Visa, GIE Bank Card, SWIFT, STET and Target 2 are trademarks ).
[0014] The merchant's account is then credited with the amount transferred while the customer's account is debited for the same amount, typically on a deferred basis. The encryption used for the exchange of data is, for example, based on a standard encryption algorithm using a public key and a private key, for example an RSA type encryption (acronym for Ronald Rivest, Adi Shamir and Leonard Adleman). Depending on their nature and / or according to the source and / or recipient devices, only certain exchanges can be encrypted. In such a standard four-corner model, a main transaction can not order one or more independent ancillary transactions, including donations, without substantial changes to the merchant's bank's and the bank's bank account management systems. associated the payment card used. According to a particular embodiment, a particular computer system is associated with a bank server to collect information relating to the execution of transactions carried out by a cardholder and to control ancillary operations, including donations operations, without changing the transaction processing. FIG. 2 schematically illustrates a first example of environment 200 in which a particular embodiment of the invention based on the four-corner model can be implemented. As illustrated, a holder of a payment card 205 can make a payment with a payment terminal 210 which is itself connected to a bank computer system 215 of a merchant's bank. This banking computer system 215 can, in turn, via a bank intermediation network 220, come into contact with a bank computer system 225 of the bank having issued the payment card used. The banking computer system 225 is connected, via the bank intermediation network 220, to a bank computer system 230 of a bank managing an account of the holder of the payment card used, on which the amount of the purchases made must be deducted. It is also connected to a server 235 implementing an ancillary operations management system. As illustrated, the server 235 implementing an ancillary operations management system is itself connected via the bank intermediation network 220 to the bank computer system 230 of a bank managing an account of the cardholder. payment used, from which the amount of the donations made must be deducted and from a banking computer system 240 of a bank managing an account associated with one or more ancillary operations to be carried out (for example an account of an NGO to whom donations are made).
[0015] It is observed here that if the banking computer system of the bank managing an account on which the amount of purchases must be deducted is the same as the banking computer system of the bank managing an account from which the amount of the donations made must be deducted. these systems and / or accounts may be different. The banking computer system 225 of the bank having issued the payment card used is preferably different from the bank computer system 230 of the bank managing an account of the holder of the payment card used, from which the amount of donations made. The communication protocols between these different banking computer systems are preferably chosen from standard protocols, for example the IF (abbreviation of the Internet Protocol in English terminology) and X.25 protocols. The bank intermediation network 220 is, for example, the banking intermediation network MasterCard, Visa, GIE Bank Card, SWIFT, STET or Target 2. The control of ancillary transactions is here carried out using a 15 identifier. associated with the payment card used and an ancillary operations management system implemented in the computer system 235 connected to the bank computer system 225 of the bank that issued the payment card used. Launching and control of side operations can be broken down into two phases, a configuration phase and a usage phase. During the configuration phase (denoted CD in FIG. 2), the card holder 205 has configured his own characteristics (which can be grouped in the form of a profile) in the computer system 235 connected to the banking computer system. 225 of the bank having issued the payment card used. Such a configuration consists, for example, in determining rules for calculating donation amounts and indicating the recipients. This configuration phase is described in more detail with reference to FIG. 3. The use phase directly targets the launch and control of side operations following the execution of a main transaction.
[0016] When performing a main transaction, for example to make a purchase of an amount M, a customer presents his payment card 205 to a payment terminal 210 of a merchant to which the amount M has been transmitted so manual or automatic. After validation of the purchase by the customer (step 0), for example by entering a PIN or PIN (acronym for Personal Identification Number in English terminology), the payment terminal 210 here performs a request for authorization ( step CD) which is transmitted to the bank computer system 225 of the bank having issued the payment card used (step 0), with the amount M, via the computer system 215 of the merchant's bank and the bank intermediation network 220. The message is advantageously encrypted and includes the identifiers of the customer and the merchant as well as the amount to be transferred.
[0017] After authentication and verification, including the identity of the customer and the merchant and the threshold amounts authorized by the payment card used, a transfer acceptance message (preferably ack), preferably encrypted, is sent by the bank computer system 225 of the bank having issued the payment card used to the computer system 215 of the merchant's bank and then to the payment terminal 210 (steps 0 and 0). After receiving a transfer acceptance message, a debit message is transmitted by the computer system 215 of the merchant's bank to the address of the bank computer system 225 of the bank that issued the payment card used (step 0). via the bank intermediation network 220. This message is preferably encrypted. A debit message is then transmitted by the bank computer system 225 of the bank having issued the payment card used to the address of the bank computer system 230 of a bank managing an account of the holder of the payment card used, on which The amount of the purchases made (step CD) must be deducted via the bank intermediation network 220. Again, this message is preferably encrypted.
[0018] It is observed here that requests for banking intermediation can be accumulated and carried out in a deferred manner. Similarly, credit and / or debit transactions can be accumulated and carried out in a deferred manner.
[0019] The merchant's account is then credited with the amount transferred while the customer's account is debited with the same amount, typically on a non-commission basis (eg a merchant commission or an international payment commission). The encryption used for data exchange is, for example, encryption using a public key and a private key, for example an RSA type encryption. The bank computer system 225 of the bank having issued the payment card used here holds an account log comprising information relating to each main transaction made, for example the amount and an identifier associated with the payment card used (but not allowing preferably, to reconstitute the number of the payment card used (this card number making it possible to make purchases)). Information from this account log is, for each payment card managed by the corresponding bank computer system, transmitted to the computer system 235 implementing an ancillary operations management system (step 0), typically a software module. They can be transmitted for each main transaction or in batches, periodically. This information is used to determine, from the configuration performed by the card holder concerned, the ancillary operations to be performed, ie, for example, to calculate an amount of donations and to identify the recipient of the donations. donations. The ancillary operations management system is described in more detail with reference to FIG. 3. As illustrated diagrammatically in FIG. 2, a payment can be made in a standard way by the transmission of a debit message from the computer system. implementing a system for managing subsidiary transactions at the address of the bank computer system 230 of a bank managing a cardholder account of the payment card used, from which the amount of purchases and / or donations must be deducted performed, and by the transmission of a credit message from the computer system 235 implementing an ancillary operations management system to the address of the bank computer system 240 of a bank managing an account of the recipient (s) of the donation ( steps 0 and 0`), via the bank intermediation network 220. According to a particular embodiment, the payment of donations (credit and debit) is made batch for a set of d ons (i.e. a donation amount ID). The payment of accumulated donations is advantageously made using a particular account managed by a third party, for example by the entity in charge of the ancillary operations management system, also called pivot account.
[0020] FIG. 3 schematically illustrates an ancillary operations management system that can be implemented, for example, in a computer system connected to a bank computer system of a bank that has issued a payment card for performing ancillary operations, for example the computer system 235 of Figure 2.
[0021] As illustrated, the ancillary operations management system 300 essentially comprises three modules 305, 310 and 315 as well as a database 320. The module 305 is a configuration module, the module 310 is a module for acquiring and configuring the data. management of ancillary operations for example donation management, and the module 315 is a calculation module, for example calculation of donations. According to a particular embodiment, the modules 305, 310 and 315 are independent of each other. As illustrated, the ancillary operations management system 300 here comprises the communication interfaces 325, 330 and 335.
[0022] The communication interface 325 allows a user to interact with the configuration module 305. This is, for example, a local communication interface (for access from a computer equipment implementing the remote operations management system 300) or remote (for access from remote computer equipment via a communication network). The communication interface 325 preferably provides encoding means for encrypting the exchanged data.
[0023] The configuration module 305 advantageously comprises a user interface cooperating with the communication interface 325 to enable a cardholder managed by the manager of the auxiliary operations management system 300 to enter and set up rules relating to ancillary operations. These rules can be stored as tables in the database 320. The access to the module can, according to a particular embodiment, be carried out from a remote computer, using a connection such that 'Internet. This access is preferably protected by an identifier and a password previously delivered to the cardholder, in a conventional manner.
[0024] Table 1, presented in the appendix, illustrates an example of rules relating to ancillary operations, here donations. Each line of the table corresponds here to a rule. According to the illustrated example, each rule is defined by an identifier (column 1), an identifier associated with a payment card or a group of identifiers associated with payment cards (column 2), a method of calculating donations ( column 3) and an identifier of a beneficiary or a group of beneficiary identifiers (column 4). Of course, other information can be used in the definition of the rules. Thus, for example, the identifier associated with a payment card can be replaced or supplemented by a customer identifier and / or a contract identifier. As previously indicated, an identifier associated with a payment card preferably does not correspond to the number of the payment card. According to a particular embodiment, such an identifier does not allow the card to be used to make a payment. When a group of beneficiaries is designated, the distribution of a donation between them is preferably predetermined.
[0025] Thus, for example, the rule having the identifier 2 applies to the payment card or the group of payment cards with the reference G53391, the beneficiaries being for a first half of a donation a beneficiary having the identifier 1 and for the second half of the donation, a beneficiary with identifier 2. The amount of the donation is here determined according to the amount of the purchases (0.5%) or in a lump sum (5E), the smallest value being retained. As described above, the setting of these rules can be done by a protected access to the ancillary operations management system 300. By way of illustration, a payment card holder can access, using an identifier which its own credit card reference and password, to all the rules associated with that identifier or reference, that is to say a subset of the rules stored. Rule access allows you to add, edit, or delete rules. Access can be from any computer, tablet, smartphone or other similar device connected to the ancillary operations management system 300 via a communication network such as the Internet and via a web-like portal. The module 310 for acquisition and management of ancillary operations, for example donation management, receives data received from the bank's computer system of the bank having issued the payment card used (typically the computer system on which the payment system is implemented). management of ancillary operations 300) via the communication interface 330. These data, from an account log, typically include an identifier associated with the payment card and one or more amounts.
[0026] They can be received by the module 310 periodically, for example daily or weekly, or on request. The received data can be stored in the database 320 to be processed by the calculation module 315 or be directly addressed to the latter.
[0027] The communication interface 330 is, for example, a local communication interface (for access from a computer equipment implementing the auxiliary operations management system 300) or remote (for access from computer equipment saying via a communication network). The communication interface 330 preferably provides encoding means for encrypting the exchanged data. The communication interface 330 is advantageously unidirectional to enable the reception of data from a banking computer system without authorizing the transmission of data to this system, thus guaranteeing, with respect to the module 310 of acquisition and management of ancillary operations, the integrity of the data managed by the banking computer system to which it is connected. The module 310 acquisition and management of ancillary operations manages the results provided by the module 315 calculation. The calculation module 315 uses the rules associated with an identifier associated with the payment card under consideration, typically an identifier received by the acquisition and management module of the ancillary operations, stored here in the database 320, to determine the operations annexes to be made. According to a particular embodiment, the module 315 performs part of the ancillary operations to be performed, such as the calculations involved without the rules, for example the calculation of donation amounts. The results obtained by the module 315 are preferably stored in the database 320, for example in the form of result logs, for example donation journals. Such a log includes, for example, for each transaction made, as shown in the attached table 2, a transaction reference (column 1), a credit card identifier (column 2), a purchase amount ( column 3), an amount of one or more donations made and the associated beneficiary (s) (column 4), being observed that the amount of a donation can be divided among several beneficiaries. A donation journal may include other information such as a merchant ID associated with the transaction that led to the 30 donations considered. In addition, the donation journal may include the amount T of the payment, representing the sum of the amount M of purchases and the amount of the corresponding gifts.
[0028] As an illustration, the log line for the transaction identified by reference 2 corresponds to a transaction carried out by a payment card referenced G53391, the amount of purchases made being 87.45E and the donation amount of 0.44E split equally among the beneficiaries identified by references 1 and 2. The results logs are accessed periodically, for example every month, by the module 310 acquisition and management of ancillary operations. In the context of donations, the module 310 determines, for example, the total amount of donations associated with a payment card in order to debit a cardholder's account and credit the designated account (s) as recipients. These debit and credit operations are carried out according to a standard scheme such as those described above, using the communication interface 335. By way of illustration, the communication interface 335 offers access to and from a banking intermediation network. It is observed here that debit and credit operations are particularly simple to implement for a bank sub-contractor. According to a particular embodiment, the result logs are kept, with an indication that the corresponding debit and credit operations have been carried out, to allow, for example, to publish donation statements that can be used in particular for fiscal purposes. Such records are typically edited on request, for example using the configuration module 305 which may include lookup tools. Figure 4 schematically illustrates a second exemplary environment 400 in which a particular embodiment of the invention can be implemented, based on the model known as a three-corner model. It will be recalled here that, according to this model of credit card payment, a single bank computer system is involved in the processing of a transaction. There is a separation between the management of the payment card system and the holding of debit and credit accounts. The single bank computer system goes through clearing and settlement systems to credit traders and debit holders. As illustrated in FIG. 4, a holder of a payment card 405 can make a payment with a payment terminal 410 which is itself connected to a single bank computing system 415. This single banking computer system 415 can in turn via a bank intermediation network 420, contacting a banking computer system 425 of the merchant's bank and with a bank computer system 430 of the bank of the cardholder used.
[0029] Finally, the single bank computing system 415 is connected to a computer system 435 implementing an ancillary operations management system. As illustrated, the computer system 435 is itself connected, via the bank intermediation network 420, to the bank computer system 430 of a bank managing an account of the holder of the payment card used, from which the amount must be deducted. donations made, and a bank computer system 440 of a bank managing an account associated with one or more ancillary operations to be performed, for example an account of an NGO.
[0030] The communication protocols between these different banking computer systems are preferably chosen from standard protocols, for example the IF and X.25 protocols. The banking intermediation network 420 is, for example, the banking intermediation network MasterCard, Visa, GIE Credit Card, SWIFT, STET 25 or Target 2. The single bank computing system 415 is, for example, an Amex type computer system. (Amex is a brand). The control of ancillary operations is here performed using an identifier associated with the payment card used and a management system 30 of ancillary operations implemented in a computer system connected to the single bank computer system.
[0031] According to the example illustrated in FIG. 4, the single bank computing system 415 is that of the bank issuing the payment card used. As previously described with reference to FIG. 2, the launch and control of ancillary operations can be broken down into two phases, a configuration phase and a usage phase. The configuration phase (denoted CD in FIG. 4) is similar to that described above with reference to FIG. 3. Again, this configuration consists, for example, in determining rules for calculating donation amounts and indicating the recipients. The use phase is aimed directly at launching and controlling side operations when a main transaction is performed. During the execution of a main transaction, for example to make a purchase of an amount M, a customer presents his payment card 405 to a payment terminal 410 of a merchant to which the amount M has been transmitted from manually or automatically. After validation of the purchase by the customer (step 0), for example by entering a PIN or PIN (acronym for Personal Identification Number in English terminology), the payment terminal 410 here makes a request for authorization to single bank computing system 415 (step CD). The message is advantageously encrypted and includes the identifiers of the customer and the merchant as well as the amount to be transferred. After authentication and verification, in particular of the identity of the customer 25 and that of the merchant as well as the thresholds of amounts authorized by the payment card used, a transfer acceptance message (denoted ack), preferably encrypted, is addressed. by the single bank computer system 415 at the payment terminal (step 0). A credit message is then transmitted by the single bank computer system 415 via the bank intermediation network 420 to the merchant bank computer system 425 (step 0).
[0032] Similarly, a debit message is transmitted by the single bank computing system 415 via the bank intermediation network 420 to the computer system 430 of a bank managing an account of the holder of the payment card used (step 0).
[0033] These debit and credit messages, targeting an amount M, are preferably encrypted. It is observed here that debit and / or credit requests can be accumulated and carried out in a deferred manner. The merchant's account is then credited with the amount transferred 10 while the customer's account is debited with the same amount, typically on a non-commission basis (eg a merchant commission or an international payment commission). The encryption used for the data exchange is, for example, an encryption using a public key and a private key, for example an RSA type encryption. The single bank computer system, linked to the bank having issued the payment card used, here holds an account log comprising information relating to each main transaction performed, for example the amount and an identifier associated with the payment card used (but preferably not making it possible to reconstitute the number of the payment card used (this card number making it possible to make purchases)). Information of this account log is, for each payment card managed by the single bank computer system 415, transmitted to an ancillary operations management system, typically a software module, of the computer system 435 (step 0). They can be transmitted for each main transaction or in batches, periodically. They are typically used to determine, from the configuration performed by the bearer of the card in question, the ancillary operations to be performed, that is, for example, to calculate an amount of gifts and to identify the recipient of the cards. donations. This ancillary operations management system may be similar to that described above with reference to FIG.
[0034] As illustrated schematically in FIG. 4, a payment of donations can be made by the ancillary operations management system of the computer system 435, as a standard, by the transmission of a debit message to the address of the banking computer system. 430 of the bank managing an account of the holder of the payment card used, on which the amount of the donations made must be deducted, and by the transmission of a credit message to the address of the banking computer system 440 of a bank managing an account of the recipient of donations (steps CD and 0 '). The debit and credit transactions are here carried out via the bank intermediation network 420. When there are several recipients for donations, several credit messages are issued. According to a particular embodiment, the payment of donations (credit and debit) is made in batches for a set of donations (i.e. an amount of donations ID). Again, the payment of accumulated donations is advantageously made using a pivot account. FIG. 5 illustrates an exemplary device that can be used to implement, at least partially, one embodiment, in particular the steps described with reference to FIGS. 2, 3 and 4. The device 500 is for example a server, a computer or a personal assistant. The device 500 preferably comprises a communication bus 502 to which are connected: a central processing unit or microprocessor 504 (CPU, acronym for Central Processing Unit in English terminology); A read-only memory 506 (ROM, acronym for Read Only Memory in English terminology) that may include the operating system and programs such as "Prog"; a random access memory or cache memory 508 (RAM, acronym for Random Access Memory in English terminology) comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs; a reader 510 of removable storage medium 512 such as a memory card or a disc, for example a DVD disc; and - a graphics card 514 connected to a screen 516. Optionally, the device 500 may also have the following elements: a hard disk 520 that may include the aforementioned "Prog" programs and data processed or to be processed according to the invention; a keyboard 522 and a mouse 524 or any other pointing device such as an optical pencil, a touch screen or a remote control enabling the user to interact with the programs according to the invention, in particular to initiate a transfer of money , set up donation request rules, follow one or more donation lists and obtain a tax receipt; and a communication interface 526 connected to a distributed communication network 528, for example the Internet network, the interface being able to transmit and receive data. The communication bus allows communication and interoperability between the various elements included in the device 500 or connected to it. The representation of the bus is not limiting and, in particular, the central unit is able to communicate instructions to any element of the device 500 directly or via another element of the device 500. The executable code of each program allowing the programmable apparatus to implement the processes according to the invention can be stored, for example, in the hard disk 520 or in the read-only memory 506.
[0035] According to one variant, the executable code of the programs can be received via the communication network 528, via the interface 526, to be stored in the same manner as that described previously. More generally, the program or programs may be loaded into one of the storage means of the device 500 before being executed. The central unit 504 will control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored in the hard disk 520 or in the read-only memory 506 or else in the other elements of aforementioned storage. When powering up, the program or programs that are stored in a non-volatile memory, for example the hard disk 520 or the read-only memory 506, are transferred into the random access memory 508 which then contains the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention. Naturally, to meet specific needs, a person skilled in the field of the invention may apply modifications in the foregoing description. The present invention is not limited to the described embodiments, other variations and combinations of features are possible. In particular, it is observed here that, for purposes of illustration, the invention has been described according to particular embodiments, there are other variants. Thus, for example, the invention can be implemented in a context of payment via the network, including Internet payments such as secure online shopping type or m-POS type (acronym for mobile Point of Sale in Anglo-Saxon terminology). Similarly, again by way of illustration, the invention can be implemented during withdrawal type operations (a donation being made for each withdrawal, according to certain thresholds or not). The present invention has been described and illustrated in the present detailed description with reference to the accompanying figures. However, the present invention is not limited to the embodiments presented. Other variants and embodiments may be deduced and implemented by the person skilled in the field of the invention upon reading the present description and the appended figures.
[0036] In the claims, the term "include" does not exclude other elements or other steps. The indefinite article "one" does not exclude the plural. A single processor or several other units may be used to implement the invention. The various features presented and / or claimed can be advantageously combined. Their presence in the description or in different dependent claims does not exclude the possibility of combining them. The reference signs can not be understood as limiting the scope of the invention.
[0037] 303 1 4 10 28 APPENDIX ID Rule REF CP RULE Beneficiary ID 0 543291 Rounding up 1 1 1294G3 Package 1E per transaction 1 (0.40E), 3 (0.60E) 2 G53391 Minimum between 0.5% of the 1 (50 %), 2 (50%) transaction and 5E ... ... ... n 491503 Rounding up 1 5 Table 1 Trans. REF CP MD, b 0 543291 425.66E 1: 0.34E 1 543291 35.14E 1: 0.86E 2 G53391 87.45E 1: 0.22E, 2: 0.22E ... ... ... ... P 1294G3 118.00E 1: 0.40E, 3: 0.60E Table 2
权利要求:
Claims (14)
[0001]
REVENDICATIONS1. A method of controlling an ancillary operation related to the execution of a main transaction, which method is characterized in that it is implemented in an ancillary operations management system (300) connected to a third party device ( 225, 415) of a bank payment set further comprising at least two separate client devices (215, 230, 425, 430), the bank payment set being configured to perform a main transaction between the two client devices, and in that it comprises the following steps, - receiving information relating to the execution of said main transaction between the two client devices, said information being received from said third party device; identification of at least one execution rule of the annex operation according to at least a first piece of information of said received information; and performing the annex operation according to said at least one identified rule and at least one second information of said received information, distinct from said first information.
[0002]
2. The method of claim 1 further comprising a step of configuring said at least one execution rule in said ancillary operations management system.
[0003]
3. The method of claim 1 or claim 2 further comprising a step of storing at least one information relating to the execution of said ancillary operation and a step of creating a history of execution of ancillary operations.
[0004]
4. Method according to any one of claims 1 to 3 wherein said step of performing the annex operation comprises a step of transmitting data to at least one device separate from said third party device.
[0005]
The method of claim 4 wherein said data transmitted to at least one device separate from said third party device comprises a debit order and a credit order.
[0006]
6. Method according to any one of claims 1 to 5 wherein said steps of identification of at least one rule and execution of the annex operation are performed periodically according to information previously received and stored.
[0007]
7. Computer program comprising instructions adapted to the implementation of each of the steps of the method according to any one of claims 1 to 6 when said program is executed on a computer.
[0008]
8. A control device for ancillary operations related to the execution of main transactions, said device being characterized in that it comprises: a database (320); a module (310) for acquiring and managing ancillary operations; and, a calculation module (315), the acquisition and management module for ancillary operations and the calculation module being configured to receive data from a third party device (225, 415) of a set bank payment system further comprising at least two separate client devices (215, 230, 425, 430), the bank payment set 20 being configured to perform a main transaction between the two client devices; and o at least partially identifying and executing an execution rule of an ancillary operation stored in the database according to received data. 25
[0009]
9. Device according to claim 8 further comprising a configuration module (305), the configuration module for storing in said database and the setting of rules for executing ancillary operations.
[0010]
The apparatus of claim 8 or claim 9 further comprising a data acquisition communication interface configured to receive data from said third party device.
[0011]
The device of claim 10 wherein said data acquisition communication interface is unidirectional.
[0012]
12. Device according to any one of claims 8 to 11 further comprising a configuration communication interface configured to allow a user to enter, set or modify a rule of execution of ancillary operations.
[0013]
The device of claim 12 wherein said configuration communication interface provides Internet access to a remote device.
[0014]
Apparatus according to any one of claims 8 to 13, further comprising a communication interface configured to transmit data to said bank payment set when performing an annex operation.
类似技术:
公开号 | 公开日 | 专利标题
US10810557B2|2020-10-20|Financial services ecosystem
US20190012665A1|2019-01-10|Systems and Methods that Utilize Blockchain Digital Certificates for Data Transactions
US20170323298A1|2017-11-09|System and method for securely transferring funds between persons
US20080046362A1|2008-02-21|Method of making secure on-line financial transactions
EP3243175A1|2017-11-15|Methods and devices for controlling ancillary operations related to the execution of main transactions
WO2018154082A1|2018-08-30|System and method for processing a banking transaction
WO2016042258A1|2016-03-24|Methods and devices for managing composite transactions
WO2004012111A2|2004-02-05|Loyalty-building method by granting a reward to an individual in consideration of an action profitable to an enterprise
EP3485451A1|2019-05-22|Method for processing at least one piece of payment means data, payment terminal and corresponding computer program
US20210042826A1|2021-02-11|Decentralized distribution system substantiated by crude oil reserves on a blockchain network
FR3011366A1|2015-04-03|METHOD OF PROCESSING TRANSACTIONAL DATA, TERMINAL, SERVER AND CORRESPONDING COMPUTER PROGRAMS.
FR2760549A1|1998-09-11|FINANCIAL TRANSACTION METHOD AND SYSTEM
EP1421564B1|2006-03-01|Payment device
EP1111555A1|2001-06-27|Electronic payment terminal and method of using same
FR3048537A1|2017-09-08|ONLINE TRANSACTION PROCESSING SYSTEM WITH ADAPTIVE ACQUIRER SELECTION
FR3050054A1|2017-10-13|
FR3056324A1|2018-03-23|DIGITAL RIGHTS MANAGEMENT PLATFORM ON CYCLE OF HIGHER STUDIES
WO2009095747A1|2009-08-06|Computerized system for modelling and operating public documents
FR2814567A1|2002-03-29|Internet purchasing system uses central database to validate goods for sale to guarantee authentic transactions
同族专利:
公开号 | 公开日
US10755361B2|2020-08-25|
US20160196591A1|2016-07-07|
EP3243175A1|2017-11-15|
FR3031410B1|2017-07-28|
WO2016110635A1|2016-07-14|
US20180268492A1|2018-09-20|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
US5466919A|1993-04-02|1995-11-14|Hovakimian; Henry|Credit/charge card system enabling purchasers to contribute to selected charities|
US6014635A|1997-12-08|2000-01-11|Shc Direct, Inc.|System and method for providing a discount credit transaction network|
US20020008146A1|1998-11-20|2002-01-24|Tara C. Singhal|Universal charity card system|
US20020120513A1|2000-03-20|2002-08-29|Webb Christopher S.|Patronage incentive saving system and method for retail businesses|
US20100145812A1|2008-05-06|2010-06-10|Worth Julian Otto|System and method for managing the generation, collection and distribution of contributions from the use of payment cards|
US6088682A|1993-02-18|2000-07-11|Every Penny Counts, Inc.|Funds distribution system connected with point of sale transactions|
US20040034563A1|1998-11-18|2004-02-19|Brissette Edward C.|System and method for making charitable donations|
US8160922B2|1999-06-23|2012-04-17|Signature Systems, LLC.|Method and system for making donations to charitable entities|
US6876971B1|2000-07-05|2005-04-05|Every Penny Counts, Inc.|Funds distribution system connected with point of sale transaction|
DE10049618A1|2000-10-05|2002-04-18|Deutsche Telekom Mobil|Process for coupling online and Internet services|
AU2002245021A1|2000-11-20|2002-07-24|Feast, Inc.|Method and system for distributing charitable donations at a point of sale to qualified donees|
US20020116214A1|2001-02-16|2002-08-22|Horn James Van|Automated fundraising accounting system|
AU2002220290A1|2001-12-14|2003-06-30|Angus Bernhardt Pohl|Computer automated electronic small change harvesting method|
US20060122856A1|2002-06-06|2006-06-08|Benevolink Corporation|System and method for enabling consumers to add personal charitable contributions and transfer the right to designate a beneficiary to other consumers|
US20040024698A1|2002-08-02|2004-02-05|William Hines|Method of facilitating charitable contributions using a credit card|
US20040182922A1|2003-03-21|2004-09-23|Frank Talarico|Systems and methods for a loadable stored-value card with a contribution to a specified beneficiary|
US20050021363A1|2003-07-25|2005-01-27|Stimson Gregory F.|Debit card per-transaction charitable contribution|
US7080775B2|2003-09-05|2006-07-25|American Cancer Society|Methods and systems for automatically determining and collecting a monetary contribution from an instrument|
US20060089874A1|2004-10-22|2006-04-27|Newman Christian D|Generating income for a beneficiary organisation and loyalty points using purchases by a consumer|
US20070080213A1|2005-10-12|2007-04-12|Workman Lloyd T|Aggregate electronic change saving method|
US20080281690A1|2007-05-09|2008-11-13|Terrence Patrick Tietzen|Method, system and computer program for providing a loyalty engine for dynamic administration of charity donations|
US8732080B2|2009-03-03|2014-05-20|Quercus Limited|System and method for executing a financial transaction|
US8732082B2|2009-03-03|2014-05-20|Quercus Limited|System and method for executing an electronic payment|
US20120084162A1|2010-10-05|2012-04-05|Merrill Brooks Smith|Systems and methods for conducting a composite bill payment transaction|
US20140229397A1|2013-02-14|2014-08-14|Michael Fink|System and method for managing charitable donations|
US9111300B2|2013-06-27|2015-08-18|Sparo Corporation|Method and system for automated online college scholarship donations|
WO2016018721A1|2014-07-30|2016-02-04|Wal-Mart Stores, Inc.|Systems and methods for roll-up payments|
US20160314466A1|2015-04-24|2016-10-27|Wal-Mart Stores, Inc.|Systems and methods for roll-up payments augmented by price matching refunds|
US10169820B2|2015-09-03|2019-01-01|Bank Of America Corporation|Systems and methods for display notifications for routing of electronic transaction processing results|
US10157420B2|2015-09-03|2018-12-18|Bank Of America Corporation|Systems and methods for additional notification and inputs of electronic transaction processing results|
US20170124538A1|2015-11-02|2017-05-04|Shea Rouda|System and method for facilitating micro-donations on payment card and other cashless transactions|
US20170243173A1|2016-02-19|2017-08-24|Coin Out Inc.|Systems and Methods for Managing Information Related to Transactions|
US20170286925A1|2016-03-31|2017-10-05|David Trubnikov|System and method for accumulating funds into an aggregate account for transacting triggered purchases|EP3273402A1|2016-07-21|2018-01-24|MasterCard International Incorporated|Method for collecting and processingelectronic donations from an financial account|
US20190220908A1|2018-01-17|2019-07-18|Galileo Processing, Inc.|Charitable giving matching via roundup|
CN108648070A|2018-05-17|2018-10-12|南京合荣欣业信息技术有限公司|A kind of cash temporary storage management method and system|
法律状态:
2015-12-30| PLFP| Fee payment|Year of fee payment: 2 |
2016-07-08| PLSC| Search report ready|Effective date: 20160708 |
2016-11-18| PLFP| Fee payment|Year of fee payment: 3 |
2017-12-22| PLFP| Fee payment|Year of fee payment: 4 |
2020-01-17| PLFP| Fee payment|Year of fee payment: 6 |
2021-07-29| PLFP| Fee payment|Year of fee payment: 7 |
优先权:
申请号 | 申请日 | 专利标题
FR1550025A|FR3031410B1|2015-01-05|2015-01-05|METHODS AND DEVICES FOR CONTROLLING ADDITIONAL OPERATIONS ASSOCIATED WITH THE EXECUTION OF MAJOR TRANSACTIONS|FR1550025A| FR3031410B1|2015-01-05|2015-01-05|METHODS AND DEVICES FOR CONTROLLING ADDITIONAL OPERATIONS ASSOCIATED WITH THE EXECUTION OF MAJOR TRANSACTIONS|
US15/541,438| US10755361B2|2015-01-05|2016-01-04|Methods and devices for controlling ancillary operations related to the execution of main transactions|
PCT/FR2016/050001| WO2016110635A1|2015-01-05|2016-01-04|Methods and devices for controlling ancillary operations related to the execution of main transactions|
EP16702164.1A| EP3243175A1|2015-01-05|2016-01-04|Methods and devices for controlling ancillary operations related to the execution of main transactions|
US14/992,352| US20160196591A1|2015-01-05|2016-01-11|System and method for making and tracking charitable contributions|
[返回顶部]